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The mission of fhe co-reslclenf operallng system task group was: "To define a cost 
effective mechamism within the new operating system to allow selected old operating 
systems to operate in their entirety permitting simultaneous execution with no modifications 
to the old operating system". 

Four people were assigned to this task, two from NCR v/ifh experience en the NCR/Century 
and two from CDC experienced with CYBER 70 computer systems. 

The scope of the problem was narrov/ed to a point where productive output could be 
obtained in the allotted time frame. It was decided the time could be spent most 
profitably in a detailed study of emulating the NCR Century computer systems on the 
IPL» This decision was heavily influenced by a desire to deal with specific problems 
rather than phi I osophi col and inconclusive 'matters. !t was also Te!t trior the productivity 
of the team would be greater if it were kept small. 

Having limited the problem in scope, various assumptions had to bo made b2:'.fore further 
progress could be accomplished. Key in fhis area was the assumption that, ihe problem 
\ws soluble. As a result, the team concentrated on hov/ to effect the implementation, 
as opposed to if it was possible. A second key assumption was that all other teams would 
be successful* Having assumed this, it v^'os net necessary to spend any time on definition 
of the host system except to equate it to tfje CYBER 70 system in terms of hardvvore and 
software capability. 

The following computer systems were identified as candidates for emulation: 

a. NCR Century I 

b. NCR 315 



c. CDC 3000L. 

The CDC CYBER 70 compufer systems were not considered to be candidates. The strategy 
for CYBER 70 systems was taken to be compatibility supported by conversion aids. It is 
felt that both the NCR 315 and CDC 3000L computer systems should be emulated, however, 
a detaiie;d study of these two systems was improcticai in the time frame. Ail three of 
these machines are'architectura!iy similar and many of the problems to be solved emulating 
one of them apply to the others. 

There are several problem areas that were covered in discussing implementation techniques 
for the century simulator. The term simulator is used deliberotely to indicate that software 
is the major tool in the process, not hardware. One major area of concern v/qs, which 
operating systems can and should be allowed in the simulatrcn environment. The user 
Interface to the Bl operating system is so broad that it does not make stJnsc to consider 
interfacing simulation below the B1 operating system level, it appears that all the B series 
operating systems can run under simulation. The coses that cannot be handled are those 
which present solid time critical situations (e.g., /vllCR) Vv'here the operation fails when 
response is not received in a certain amount of time. 

The main difference befween SCOPE and B series operating systems soeim to be in the 
handling of I/O devices. CDC's approach is loglcul right to the point of transfer of 
data. In the NCR sysrcrns, binding to devices is done much erfrlior ~ partly in the 
source program, and partly at program load time. Many of the problems to be solved in 
the simulator design stem from this basic philosophical difference. 



Problem areas discussed other than I/O were: 

a. Privileged commands. 

b. Supervisor colls. 

c. Implicit configuration control, 

d. Operator communications. 

e. Idle loops. 

fo Engineering and accounting logs, 

g. Feature redundancy* 

h. Remote Job Entry. 

i. Syst.em initialization, 

j. Real time considerations. 

All of these points are discussed in detail in Section 5.2 of the report. 

As stated previously it seems that all levels of B series operating systems can be simulated. 
The provision for simulating 34 in addition to Bl v/as considered. On the surface it 
appears that B4 need not be simulated since its primary function is io multiprogran:, Wlih 
multiple B1 jobs and a simulator being shared, through a shared cocfe facility provided by 
the host OS^ the differences between the two approaches are not obvious. However, 
provision for B4 simulation a! lows the I oaot change for the user and vendor ot a possibly 
substantial performance cost to the user. In the light of these considerations, arciumenis 
in support of both approaches can be rnado. 

After analyzing the simulation problem from many angles it appears there are three 
different solutions that may be arrived at: 
L Partitioned Configuration. 



Can utilize NCR standalone system software under simulation with 
minimum change. 

Direct drive peripherals as NCR native devices. 

Utilize "RJE type" job interchange between Host OS and simulated OS. 
Applies best to configurations having a small number of peripheral devices. 

Allows customer and use to continue to use existing operation^ administrative 
and usage protocols. 

Least development expense. 

Moderate relative performance (SWAG). 

Least aiiroctive to user because of disjoint system bur I eosr user conversion, 

2. Host Imbedded Simulator Support Package (wiih direci driven peripherols) 

Total configuration control is maintained bv Host OS. 

Common l/Q queues and inpui/output prcc-:dvces. 

Applies best to configurations having a moderate to largo number of 
peripherals. 



Mo3f developmenf expense. 

Worst relative performance (SWAG) 

Moderote attractiveness and user conversion* 

3. Host Imbedded Simulator Support Package (with peripherols driven 

through host OS). 

Total configuration control is maintained by Host OS. 

Total control of I/O support is maintained by Host OS. 

Applies best to configurations having a large number of peripherals 
and/or a large real memory capacity. 

Moderate development expense. 

Best relative performance (SWAG) 

Most aftrictive to users but requires greatest user conversion. 



The peripheral support* question seems to reduce to the following cose analysis: 

7C I devices 



1. Simulator direct driving peripherals 

^C II devices 



-Jfi I devices 
2. Simulator uses Host OS I/O services^^ 

^IPL devices 

(the double arrow indicates expected utilization density) 

Case^M is in fact the same case as that for NCR supporting its standalone custcmer 

base. The results of this NCR support in conjunction with the recommended partitioned 

configuration solution will be no additional effort for vendor or customer when moving 

to the IPL 

Case ^2 will invalidate the partitioned configuration solutiono It essentially requires 
that the Host OS and/or simulator become intimately aware of the inherent characteristics 
of the i/O structures and ptotocols for both CENTURY I and IPL systems. 

It may be stated that in general this case complicates the process for boH> vendor 
and customer. The vendor must develop end maintoin a more cc.-^^plicated simulator 
pcickooo fhor is In adcllricn to the standord OS ofrennor.>, The customor must ccnveri* his 
doia fifes from the CENTURY I devico to the corresponding iPL d^.vice^ (perhaps the iVioM' 
c ompiex and difficult portion of any conversion effort). 



Implementafion cosfs of fhe simulator were esUmafed to be no more than $1 M, regardless 
of the approach, when all efforts are included. Maintenance costs will be $25 K yearly. 
The simulator would run at on execution rate approximately double that of a Century I - 
300 and would leave at least 25% of the IPL processor free for other Work. 
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1.0 EXECUTIVE SUMMARY 

1.1 The mission of the co-resident operating systems task force was to 
deduce a mechanism whereby existing NCR and CDC computer systems 
could be emulated on the joint companies Integrated Product Line (IPL). 

1.2 The following computer systems were identified as candidates for emulation: 

a. NCR CENTURY T 

b. NCR 315 

c. CDC3000L 

The CDC CYBER 70 computer systems were not considered to be candidates. 
The strategy for these systems was taken to be compatibility supported 
by conversion aids. 

1.3 The NCR/CENTURY series were analyzed in detail and on optimum 
solution involving partitioning of the hardware was devised, implementation 
costs of the emulator. were estimated to be $1 M with maintenance costs 

of $25K yearly. The emulator would run at on execution rate approximately 
double that of a CENTURY i/300, and v/ould leave ot leost 25% of ihe 
IPL processor free for other work, 

1.4 A more general solution utilizing true co-residency was anolyzed In 
depth and shown to have similar coris but Vy'hh o $iichriy degraded 
performance over the pcrtitlcnol technique. For this reason, tt was not 
favored for implementation. 
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2.0 INTRODUCTION 

2.1 The mission of the co-resident- operating system task group was: 

"To define a cost effective mechanism within the new operating system 
to allow selected old operating systems to operate in their entirety 
permitting simultaneous execution v/ith no modifications to the old 
operating systems." 

Four people were assigned to this task, two from NCR with experience 
on the NCR/century computer systems, and two from CDC experienced 
with CYBER 70 computer systems* The task was to Be addressed over 
a six-week period. 

2.2 It was apparent from the outset that the schedule wos extremely tight, 
and with intervening meetings of the co-chairmen there were very 
few working days when the team could meet. For this reason, the 
first step taken was to narrow the problem dov/n to a point where 
productive outpuf could be obtained in the allotted timafrome. To 
this end, it was decided rhct the time couk; ;;3 spent nu:*:!' proFHabiy 
in a detailed study of emulating the NCR/CENTURY coir.pi:r'>r systems 
on the IPL. This decision v/as heavily influenced by a do^ire- fo deal 
with specific problems rather than philo'^^ophical and Inconclusive 
matters. It was also felt that the productivity of 1 no team v/ould ba 
greater if it were kept small. All that remained was to make maximum 
use of the expertise of the team members. 
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2.3 If is not suggesled that- NCR/CENTURY computers are the only candidates 
for emulation on the IPL. In fact, it was felt that both NCR 315 and 
CDC 3000L computer systems should be emulated. However, a detailed 
study of all these systems was impractical in the time available* Fortunately, 
all oF these machines are archllecturally similar, single channel, single 
processor, programmable channel interrupt driven computers, and many 

of the problems to be solved emulating one of them apply to the othL-:rs, 

2.4 Having limited the problem in scope, various assumpHons hod to be nuide 
before any further progress could be made. Key in this creo v/as the 
assumption thof.the problem was soluble. As a result, the team 
concentrated on how to effect on implementation, as opposed to If it 
was possible. Naturally, the former approach yields^ the latter answer, 
whether positive or negative* 

A second key assumption was that all other teams would be successfuL 
This ossumption implicitly defined the host computer systerru il* was 
not necessary to detail this system in any moro depth than ^ .HJtvalencInn 
it to CYBER 70 systems in terms of hardvv'ore and soflv/are c-. ...abilities. 

2.5 The bulk of this paper describes the impiemenlation techniques for trie 
sirnulotor. The term simulator is used deliberotely to indicate thct 
software Is the major too! in the process, not hardware. Tha mo5t 
complete analysis covered co-resident systems, which was the mission* 
However, a slightly different approach for the NCR/CENTURY simulation 
was investigated and favored for that system. In that approach, the 

host computer system hardware is partitioned, yielding essentially a 
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standalone CENTURY I emulator. This solufion Is not necessarily a . 
general solution for all computer systems, but it does fit in well with 
the current development plans of the two companies. It is influenced 
greatly by peripheral configurations and the transition paths which 
may be taken between current NCR/C£NTURY i peripherals and 
CENTURY Il/IPL peripherals. For this reason particular attention 
was given to problems in that area and a separate section devoted 
to them. 
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3.0 SCOPE OF THE PROBLEM 



3.1 Systems Considered 



In the interests of limiting the scope of the problem to a manageable 
size, computers not manufactured by either CDC or NCR were not 
considered for emulation by the IPL. The computers and operating 



systems consiaered were: 

3.1.1 CDC3000L 

3.1.2 CDC3111L 

3.1.3 CDC -CYBER 70 

3.1.4 CDC- CYBER 70 

3.1.5 CDC- CYBER 70 

3.1.6 NCR 315 

3.1.7 NCR 315 RMC 



- MS OS 
-MASTER 

- SCOPE 3.4 V 

- KRONOS 2.1. 

- SCOPE 2.0 
-OS 

- OS 



Lower CYBER 
Upper CYBER 



3.1.8 NCR - CENTURY I - B series as follows: 
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-3 


-3 


-3 




300 


-3 


-3 


-3 


-3 
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3,2 Selection Criferia 

3.2.1 CDC 3000L - MSOS/MASTER 

These computer systems were considered to be definite candidates 
for emulation on the IPL. However, it was decided not to address 
them specifically v/ifh the current committee* The NCR committee 
members could offer little expertise in the area, and the CDC 
committee members* experience was primarily on CDC-CV? .v: 
computers. It was felt that 3C00L emulation vvc:. basicc.<i!, .•: 
internal CDC problem and increasing the team mamber^lnp 
to address that problem would dilute the overall effort. In 
addition, the machine is architecturally similar to the NCR 
CENTURY computers v/ith respect to emulation. By that, if is 
meant that both machines are single level memory, single p 
computers. 

3.2.2 CDC CYBER 70 - SCOPE 3.4/2.0 - KRONOS 2.1 

Those computer sys]'on\3 wera not regc:r:;::d cs can -■^^ Icz for 
emulation. The current CDC strategy !? .lor to en -iiialsCYBfR 
70 systems on the iPL computers. Tha doJnn obiec ives ara 
for maximum compolibility v/iih CYDriR 70 ond to ecss the con- 
version problem that the user must face. The current CDC/NCR 
study effort has not uncovered any facts vvhich v/ould coufD ihe 
strategy to be revised. 
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3.2.3 NCR 315/315 RMC OS 

. It* was decided that* these computer systems would not be addressed 
specifically by the committee. The/ are, nevertheless, candidates 
for emulation. The NCR CENTURY cornputers using the Bl operating 
system currently simulate the 315 rr.achincs, wltli hardware assistance 
for instruction emulation. 315 I/O sirr:ulation is performed In software 
under Bl. Hence the problem has been solved, end further t^f Fort 
in this area at this time would not be utilizing resources at hand 
in an optimum fashion. 

3.2.4 NCR CENTURY - B Series OS 

These current NCR computer systems are prime candidates for emulation 
on the If^L, and it v/as decided that the team v/ould devote most of 
Itsenergies in this direction. The team members experfise 
matched to this exercise, hence the maximum benefit can be derived 
by drawing on this expertise. 

3.3 Final Selection 

In arriving at a single system for the emuiavion stuoy, -iho comrnirrviC; recOiinized 
that much work v/ou!d remain in other areas - nok?b!y 3000L. Op. ihe oiher 
hand, many of ihe techniques applied to CENTURY emulation will apply to 
3000L enuJiation, and it Is onlicipated the:? mony of the problem areas, if not 
the specific solutions, will bo common to both systems. The team had a strong 
desire to deal with specific problems, in detail, and not to address the overall 
issue in a philosophical vein. For this reason, co-opting further members onto 
the team was seen as detrimental, and the problem was narrowed down to make 
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optimal use of the limifed time-frame and full utilize the talent of the team 
members. It must be remembered that CDC 3000L, NCR 315, and NCR CENTURY 
computer systems were all identified as candidates for emulation. The NCR 
CENTURY series will be considered in detail here. 
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4. ASSUMPTIONS 

Since the IPL hardware and software, at best, are ill-defined at the present 
time, several assumptions must be made regarding the general environment. 
These assumptions are discussed below. 
4 J The objective of the exercise is total hardware emulation os opposed 

to the reproduction of selected operating system functions. All CENTURY 
operating system code and user applicafionprcnrcms are to execui-e 
on the IPL without change. 

Substantial impact - no examination v/as made into the posr,il.){lity 
^of directly supporting any level of NCR user jobs within the 
IPL OS (i.e., no simulation requirement). 

4.2 The problem is assumed to be soluble in that similar problems have been 
solved successfully in the past. 

Substantial impact - led to o detailed study of the specifics of 
the problem rather than the generalities of emulaticn/simuldticn. 

4.3 The IPL operating syol'ern is assumed to be at lowv C3 pow virfu! as CYCCTl 70 
SCOPE 3.4 In addition, vha logical ccnstrucis uC'tvd in SCOPE 3.4 arc 
assumed to exist in the nevy system in a similar forin. 

Minor impact - used as a point or rvv::renco for Host OS. 
copobilities. 

4.4 It is assumed that the simulated system con obtain direct access to 
dedicated physical devices. 

Substantial impact - the partitioned configuration solution was 
a direct fallout from this assumption.. In an embedded solution 
the main effect is on the Host OS I/O devices and the extra 
development costs for these drivers. 
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4.5 The hardware insfrucfion repertoire on fhe IPL is assumed to be roughly 
OS powerful and flexible as that of CYBER 70 today. In this context the 
6150, CYBER up CPU and CYBER 70 FPU or IPL CPU/PPU are assumed to 
be approximately equivalent processorso 

Substantial impact - no study was mode in the area of traditicna! 
"emulators". In particular, no dependence was made on the 
copabilities of the CPU supplying the processing pov/er. 

4.6 As a follbv/-on to the previous assumption, simulctlon as opposed to 
emulation is taken as the key area for investigation. Simulation being 
defined as imitation by scftv/are, emulation as imitation by hardware. 

Substontial impact - no study was made in the area of traditional 
"emulators". In particular, no dependence was made on the 
capabilities of the.CPU supplying the processing power. 

4.7 It is assumed that NCR will implement a CENTURY I simulator on the 6150 
for their standalone customer base. 

Sub:fcnticl inipccl - thn parfiticnod conflcurciion solunon 

was a direct fallout of this assumption. 
4.3 . /... it-is assumed that the 6150 is an Integrai cornponenr of {?L, being eithcv 
a peripheral processor or a centra! processor, but, in any event, being 
present on oli IPL systems^ 

Sub:4antial impact - this a!lov.^s oil NCR sicndalone system sofiworo 

to be considered for use in a partitioned IPL configuration. 
4.9 The CENTURY 300 and large 200 systems are considered the major 

candidates for simulation on the IPL. All other CENTURY series machines 
will bo accommodated thru existing upward compatibility within the 
CENTURY I series. 



4-3 



4.9 



Minor Inipacf. - reduced scope of problem. 
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5/ ANALYSIS OF THE PRODI EM 

5J CENTURY I Operafing Systems 

In order to simulate the CENTURY I operating systems, it is necessary to 
have a thorough understanding of the features offered by these systems, 
and the techniques used to implement ih^m. A complete descrlpMon 
of the B-series operating systems is out of place in this document; instertd, 
their salient features v/i!l be noted and major differences In phiiosoplv/ 
with CYBER sysrems v/i!I be pointed out. 
5.K1 B1 Operating System 

This IS a monoprogramming operating system which processes soma 
basic control cards and assists the userwifh I/O organi2:a^ion• As 
such, it may best be regarded as a Job Supervisor or Job Monitor . 
similar to the FORTRAN Monitor on the IBM 7090. The system uses 
3-1/2K bytes of memory and requires a system disk for its operation. 
It is widely used on CENTURY I models 50, 100, 101, and 200. 
The interface beiv/een user job imd the OS is v/ell defined bui is 
frequcnJ-ly violated. For the purposes of this report it wtU b^' rdcirn 
as a given that toial simulavlon of the Bl oporarinc) sv-$icrn v i;i be 
provided. 
5.1.2 B2 Operoting System 

B2 was developed to handle on-line, rBal-!irne devices - 
typically terminals. A tasking capability was added in B2 al (hough 
typically only one task runs under B2, servicing a number 
of terminals. There is a millisecond call -by-interrupt real-time 
clock running under B2 which is used to time-out users. There 
are no known time critical problems under B2. (Time critical is 



5Jo2 defined to mean where failure to respond in a given time frame. 
results in failure of the effort). At worst, slow simulation 
would lengthen the response time at the terminal, which could lead 
to operator/user frustration. However, such irritation does not 
preclude simularlon, and for the balance of this report B2 simulation 
will be considered equivalent to B1 simulcrion. 

5.1.3 B3 Operating System 

B3 is a multiprogramming operating system which simultaneousiy 
executes a fixed number of jobs. Each job is under the control of a 
separate copy of B1 or B2. Memory is allocated in Fixed segments, 
and the processor is shared by different programs, thereby giving 
better utilization during I/O processing. Device allocation and 
basic multiprogramming system used by the larger CENTURY I 
machines -the 200, 251, and 300. 

5.1.4 B4 Operating System 

This system is the logical extension to E>3 end provides general rnotnory 
management facilities. The Bl or B2 segments controinng JoU are 
no longer constrained to fixed memory areas. B4 is o la^go sysvem 
(64K - 8(K bytes) v/liich offers unit record spooling, j:6 accounting^ 
ond job control via a job speclficoiion ionguogc, in ackiltion io 
other features not found in B3. It Is a new system whlcli is currently 
In use at only a few sites. However, in the IPL time-frame 
(1975-1976), it is anticipated that it will be the system favored 
by most CENTURY 251 and up customers, and will therefore become 
the major OS considered in this report. 



5.1.5 B-Serles Variants 

Along with the four basic systems described above (B1-B4), 
there are numerous variants which take advantage of hardware 
features found only on the larger machines. These variants are 

are hardware related, rather than softv/are rciai-ed/ the impact on 
the proposed simulator is expected to be minimal. There is one 
variant not cataloged, namely the NCR rlii^.e -sharing system which 
runs BASIC and performs njany of the functions of the B2 operating 
system. It is not proposed to analyze this system in detail, 
5A.6 Differences Betv/een CDC and NCR Systems 

Perhaps the most important and most significant difference between 
SCOPE/kRONOS operating systems and the B-Series lies in the 
handling of I/O devices. CDC approaches the problem in a 
logical fashlono The user refers to logical file names, and logical 
device types, the operator refers to a lonlcal dovic^^ rK^rt:e, The 
binding of logical files to physical d^- vice-; is a dynoinic function 
which does not take place until acJu:/l date transfer occurs. The 
NCR systems ore dic!Tietrlcally opp. ;:d to ihfs po;lticr). Devices 
ore referred to by their physicci c:! jrcsses, (actuoT channel, 
equipment and unit numbers are used), and binding to device types 
Is performed early (in the source language) and is static. Many of 
the problems to be solved in the simulator design stem from this 
basic philosophical difference. 
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5,2 General Simulator Design 

5.2J Users issue i-wo types of instruction to the CENTURY I computer: normal 
commands and privileged commands. The normal commands may be 
simulated directly and require no special actions on the part of the 
host system. Privileged commands deol with I/O and control of the 
system, and, in general, require thcr :.c.T.e special ccllon be tolcen by 
the host system or by the simulator, A list of these privileged commands 
follows: 

INOUT - The only I/O command on CENTURY comourers. 

WAIT! - Pause for operator action, 

SVv'iN - With appropriate address field, reads eight console 

sv/itches into a byte; otherwise used as a supervisor 
ca!L 

■ ■ I ; ■ ,.■ ., : .■'.■•■■, . 

LDMONR - Debug aid to breakpoint a program or place 

machine in step-mode. 

LDBAR - Sets bounds regisiei^, 

IPON - Interrupt psrr.ii on. 

IPC)FF - interrupt perm! 1 off, 

Lootcally than, instructions are divi:t:c' into two caiogories by f\r^ 
simulator. Two oiher conditions mu:si !>e treated by the simulator. The 
CENTUrlY 1 computer is interrupt driven and permn?: an Instrucnon to bu 
repeated a sot number of times. Even if the hoU $yitem is not interrupt 
driven, Interrupts u\m\ bo simulated for the CENTURY I environment to 
ba totally reflected by the simulator/ 



5.2.2 A general block diagram of the simulator is shown in Figure 5.1. The 
box labelled "SETUP" simulates the instruction fetch of the CENTURY I 

and also simulates I/O interrupts. It is recognized that much remains hidden 
in this box, and the reasons for not breaking it down further are explained 
below. The privileged instructions requiring special action are shov/n 
on the right-hand side of the diagram end are discussed in some deroil in 
the following paragraphs. If had been the intention of the team, having 
reached this step, to construct block diagrams for each CENTURY I 
hardware instruction. The diagrams v/ould be broken dov/n to the level 
where each box corresponded roughly to a 6 150 insiTuction. It was hoped 
by this technique to establish cpproximare performance data for the 
simulator. Happily, this task was rendered unnecessary by the fact that 
NCR had already progressed beyond here to actual coding examples. 

Their resulting timing data has been utilized for cost/performance analyses 

■ i ■ 
discussed at a later stage, in addition to the basic instructions, NCR have 

also analyzed ond coded the setup procero wliich v/as der>cribed obove. 

5.2.3 Only the privileged Instructions INCUT, WAiTI, end SWIN ore s!^o\vn 
on the block diagram since the remainder can be horidled vv'ithouv ony 
interaction v/ith the host system* The excepticn is LDMONR, which is 
strictly a debug old. it v/os felt that the primary emphc::is shouiJ be 
placed on th:^ simulation of production codes, and certainly in tli? inJtioi 
Implementation debug aids could be omitted (NOOPod). There moy also 
be marketing reasons for omitting the command from the simulator if it 

is desirable to have users make the transition from CENTURY I to IPL. 
Such philosophical reasons aside, there are no particular difficulties which 
were foreseen in simulating this command. 



5.2.4 The INOUT Command 

There are several problems ossociafed with the INOUT command which 
are investigated in the following points. 
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5.2,4. 1 Transformafi on of naming conventions 

NCR identifies a device type by its physical 
address, that is, Its trunk (T), position (P), and 
unit (U) numbers, or in CDC terminology its 
channel, equipment, and unit numbers. It is 
necessary for the simulator to moke the trans- 
lation from TPU to device type, end ihis can be 
done by constructing tables In the s'rnulator as 
it Is loaded. The B~series operating systems 
receive the same data via control cards (PAL 

cards) and the simulator input would parallel 

■■.,■• 

these entries. A suggested format of these en- 
tries in the simulator would be: 
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The flog v/ould indicate whether or not the INPUT 
being processed represented the first access to 
that pari I cuior device. Th.e general flow for 
INOUTIs therefore: 

a. Locate PAF 

b. Extract TPU and control word (CW) 

c. If first access then REQUEST device from 
host operating system. 



d. Translate TPU to Ifn. 

e. Translate request code, 

f. Transform data/buffer formats. 

g. Issue host I/O request. 

L M^^.^fp t,/--) .^,.;.:, -t,, j-^t r-^r nKippD 

fast. 
i. ' Insert S2 status. 

5.2.4.2 Translation of TPU to Ifn 

Logical file names may be constructed by 
appending any alphanumeric character at the 
beginning of the TPU. For example, if the TPU 
was 6700/ the Ifn could be A6700. 

5.2.4.3 Operator Messages 

ITiese will always be a problem in the simulated 
environment. The problem may bo eared by es- 
tablishing conventions for clrnulirfcd jobs. For 
example, if a vser issued messages to cHsmounf ona 
pack and mount anoiher, then the operator v/cu!d 
do exactly thot - niountirtg the new pack on th.s 
$anie drive. 

5.2.4.4 Alternative Solution . 

A more general solution to this entire problem area is 
to make physical device assignments, support NCI^^ 
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CENTURY peripherals directly, and dedicate a 
PPU to the simulator. 

5.2.5 The SWIN Command 

The general flow of the simulated SWIN command is shown in 
Figure 5.2. If the SV/IN is a normal hardware instruction >o 
read the console keys, then simulation will involve inreractjon 
with the host operator, or reading simulated keys held v/Ithin rhe 
simulator field length. There may be a problem if NCv'CENTUR 
devices are not driven directly, since the SWIN command Is 
used when calling on the operating system to share devices. 

•■■■''. 

5.2.6 The WAITI Command 

This command may be simulated directly by a call to the host to 
PAUSE, followed by operator action. 

5.2.7 Clncr Problem Areas 

Several other problem areas were Identified by trie learn and 
solutions to them were proposed. Those problems and solutions 
ore discussed below:. 

5.2.7. 1 Data Poih Tror.:vFormatlcn 

File control procedures used on ihe CENTURY I 
computers are unique to them and are difficult to 
simulate. The simplest solution to this problem is 
to provide special PP codes that use the NClVCENTURY 
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. file control procedures and tables. 

5.2*7.2 Implicit Configuration Control 

On the NCIV^CENTURY computers, the config- 
uration is controlled either by personal communication 
with the operator or by informal operator messages ct 
the B 1/2/3 level. B4 adds some explicit capability 
via control cards or by a, formal protocol ; Circum- 
venting informal operator directives is a pvvriicuiarjy 
difficult problem and three alterncHves vy-ere postulated: 

a. Design the simulator such that it is sensitive to 
message content. This solution was discarded by 
the team due to its EXTREME compiexity. 

b. Provide tools within the simulator for the opera- 
tor to determine the state of the simulated B- 
series environment. In addition, cm operations 
protocol would have io be establis: .: J r:< to he..- 
to use the tools provided. . 

c. Assuming that NCfV'Ct-NTURY devices arc 
direct driven via a dedicated PPU, then the 
problem is aufomatlcaHy eliniinated,. end 
operator action would be identical to that 
seen today in the CENTURY I environment. 
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5.2.7.2 B4 Operator Displays 

The general displays set up by B4 for the operator 
will need special actions by the simulator, part- 
icularly where touch plates are concerned. Normal 
device simuloi-ion through the host console should 
suffice to eliminale this problem. Toucli !<eys are 
simulated by operator type-in and flog setilngs ]n 
the simulator. 

5.2.7.4 Idle Loops 

It is imperative that the host OS control any idling 
in the system. Idle loops in B4, for example, must 
relinquish control to the host Immediately. There are 
two types of idle loops: transient (a job or jobs in the 
system but v/aiiing for l/O moybeXand permanent - no 
more jobs to run. The simulated system m\K>l be modified 
lo return control to the host v/ner^ever thc7 .U?. loop Ig 
entered. In return, the host musr give cor :: jI back 
lo ihe simulator on previously listed conditions being 
met. V%en the "no job" idle condition occurs, then 
the operator mu.vt be interrogated for subsequent action. 

5.2.7.5 Engineering/Accounting Logs 

The host system will maintain both engineering and 
accounting logs. These logs, or portions of them, 
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may be duplicafed by the simulated system, and 
accounting may become confused in the process. 
The two logs are addressed separately. 

5.2.7.5.1 Engineering Logs 

The host system is responsible for logging 
all activity on physical devices (including, 
memory parity errors) and this information, 
in general, will not be passed on to the 
simulated system for duplication. VVliere 
the simulator is using direct drive NCIV' 
CENTURY devices, error data will be 
handed back to the simulated operating 
system for logging there. The maintenance 
engineers, in this case, will have a choice 
of the source of data for their maintenance 
activities. 

5.2.7.5.2 Accounting Logs 

The occountifu:; informaricn will be kept in 
the simulated system, typicolly I'l since 81 
does not perform any accounting functions. 
The difficulty is in absorbing the overhead 
due to simulation. The degree of difficulty 



in a rigorous solution to this problem by 
far outvveighs the benefits derived by such 
an exercise, hence such a solution should 
not be attempted* In the B1, simulated 
cnviroriir.ent, accounrlng will be accornp- 
. Iished by the host system/ and the simulator 
overhead will be obscrbed by tlie user 
automatically. This entire probl am area 
IS not regarded as serious, since Few 
NCfV'CENTURY customers ere known to 
use accounting procedures. 

5^2.7.6 Feature Redundancy 

Many features will be duplicated by the host and sim- 
ulated systems, for example: 

© spooling 

© accounting/engineering loc:5. 

G operator communication 

o data tronsforrnanon 

device error recovery 

© job centre! language, etc • 
It IS desirable, to maximize performance, to minimize these 
redundant activities. Some of these problems are addressed 
separately. Spooling appears to be a major problem which 



Will require special attenfion. A solution Is to modify 
the simulated system (B4) to eliminate the feature from 
It. This particular form of solution has been avoided 
here by incurring the penalty of an additional disc to 
disc transfer to simulate the spooling function of P'^ . In 
such cases, trade-offs will have to be made betv^cen 
exact simulation and performance. 

5.2.7.7 Remote Job Entry 

This is a particularly difficult problem in the B4 sim- 
ulated mode since the job being run by the host is the 
Simulator. Jobs submitted to B4 by NCIV^CENTURY 
users enter the host system as data to the simulator. !t 
is difficult to arrange for this data to be submitted, 
without demand, from a remote site. The problem 
evoporGies In the Bl, onvironment, and considerunon 
is given to such a simulation in a later tecilon of thJs 
paper. The normoi modus operandi of If /r ;\Crv' CENTURY 
syslem Is not RJl", hence ihe problem is iiof seen as a 
major one. 

5.2.7.8 Writing on Syclem Disc 

What amounts to a common, read only disc in the host 
system is written on by Individual Bl partitions. 



Assuming that NCR/CENTURY devices are direct 
devices, there is no problem since in the B4 environ- 
ment a solution has already been found; and in the Bl 
environment the host will only permit one Bl simulation 
to execute at one time per physical device. This v/ill 
not require any special action on the part of i\\e '-ost If 
it is assumed that there are only sufficient device: for 
one simulation. Normal resource clioconon oigorlthms 
will solve the problem. Where the NCiy'CENTURY 
devices are simulated on the host disc, then multiple 
copies of the simulated system file will be made on the 
host disc, and users granted read, write, modify, and 
extend permission on the copied files. 



5.2.7.9 System Initialization 



In any simulated environment such as that proposed here^ 
it is Importont to insure that the simulated computer ccn ■ 
be inltiolized/deaditarted in en orderly fci^hlon. The 
simulator v/il! bo loaded as a'ncwnai job in the hoit 
system, end its first task will be fo process lis control 
cords. It has already been dlscrfbed how If Is nece£..'ary 
to describe the configuration to the simulator prior to 
execution of a simulated job. The simulator would next 
create the bootstrap code, normally supplied by hardware, 
then ' cecute that code as a regular simulated sequence. 
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Since fhe sysfem inifializafion process is usually a 
somewhat lengfhy process, it is recommended that a 
checkpoint dump be made on completion of it and 
that subsequent usage commence from that point. 

5.2.7.10 Real-Time ConsidziraMons 

This problem is defined as the failure to respond to aPi 
. external stimulus in a given time—frame caosing the pro- 
cess to fail. A secondary issue is failure tc respond to 
an external stimulus resulting in inefficiency or 
operator/user frustration. The primary case does not 
have a general solution. Either the simulator is fast 
enough to handle the required response time or it is not. 
If the simulator is not fast enough/ then the application 
must be placed on the host computer. The only applicat- 
ion or device on NCR/CENTIJRY equipmeni knov/n to 
fall into this category is the MiCR. On this device a 
chock is read; and, while Ills moving through the reed er, 
computations are poi rc;r.::;d Ir-' rou'e it to the correct 
output hopper. If th:v^' computoHons ere not completed 
before ihe check reaclu:;:* ihe output hoppers, then the 
check is automatically rejected by the device. All 
other time dependent situations on NCR computers appear 
to be of the secondary type of consideration. 
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5.3 An Alternative Approach 

5*3. 1 In the preceding pages the general problem of simulating one 

computer system on another has been addressed. The NCIV'CENTURY 
series of computers has been investigated in detail, problem areas 
identified, and solutions proposed. It is postulated that the problems 
with that machine are not unique, but many of them, and their 
solutions, v^ill apply to other computer systems such ps CDC'i 
3000L series. For this reason, ihe probleru hos b3on addressed jn a 
fairly general fashion, and no assumptions hove been made regardir^g 
specific hardware configurations of the host computer. However, if 
probably configurations are considered together with current NCR 
development activities, then alternative approaches to the task in 
hand present themselves. 

5.3.2 Configuration 

The general, likely, configuration for the IPL is ihown in Figure 5.3. 
A key element in this configuration is the NCR 6150 computer. 
Currently, NCR is engaged in a deveiopr :r;i pro^rant for a CENTURA 
computer, namely the 6150, aid CumTURY i :^irvu.!L.ror$ are under 

development for ihis computer. It is noi difficult to esfabiish a 

I. 
growth pattern for a CENTURY user From ihis configuration, and a 

viable pattern is shown in Figure 5.4. If Ihis train of thought is 

pursued even furlhoi, then it is readily apparent that the entire task 

of simulation of the NCR/CENTURY computer can be achieved by 

a logical segmentafion of the hardware. This logical separation of 
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a portion of the hardware by the host system will be termed 
•'partitioning" in the remainder of this report. 

5.3.3 The advantages of partitioning are numerous. Many of the problems 

already discussed disappear in this environment. The hardware grov/th 
pattern follows the general IPL approach. Duplicity of effort is 
eliminated or minimized. Against these advantages are the Intro- 
duction of a difficult transition problam from the simulated to the 
real environment. In addition, some extra hardware rnay be required 
to drive both the NCI^CENTURY l/O device? and tlve IPL l/C 
devices. The transitional steps v/ould be: 

a. Run In a dedicated, simulated CENTURY I mbde. 

b. Alternate between the IPL mode and dedicated CENTURY I 
mode. 

c. Run the IPL mode and CENTURY I mode concurrently. 

d. Run in IPL native mode only. 

e. Run an Integrated IPl/CENTUuY I system. By \Uh Is meci.v ;har 
the additional development steps v/ou!d be req?ii; ^v to: 

(1) Exchange jobs; 

(2) Exchange Job steps; 

(3) Exchange eniiro files; 

(4) Exchange partial files. 
The exact course chosen here will probably be dictated by market- 
ing strategies and other less technically oriented factors. 
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5.3.4 Given that the NCR 6150 is an integral part of the IPL, and given 
that NCR devices will be direct driven by the IPL, and given that 
NCR are pursuing the 6150 as a stand-alone CENTURY I emulator, 
then the partitioned approach Js the favored approach. It is a 
solution unique to the CENTUkY I problem and a similar approach 
for other computer systems does not follow cutonioticoM;/ c£. a 
corollary to this argument. 

5.4 O perating System Simulation Considerations 

5.4.1 The overall problem of simulating the CENTURY ! computer system 
may be addressed at several levels. The approach of providing like 
operating system functions and executing user code directly Was con- 
sidered but rejected due to the relative ease of alternate techniques 
which have substantially smaller effects on the host operating system 
and provide comprable service and performance to the customer and 
user. The possibility of simulating eit.her the Bl operating system 
or the B4 operating system was considered olso. Cn Hie suif^c'; 
there appears to be little gained !:)y simulotn^g My since its p:!njary 
funcfion is lo rnultlnrogrom sevora! jcb:-, ecrh uivJor i'he contiol of a 
Bl system. It can safely be ar.sumed »!-:■ i':.^ \\o:A system will be a 
muftiprogrGrnming system, in v/hich case by simulanng Bl It vA\\ 
provide many of the basic facilities supplied by B4, and thereby 
eliminate the need to simulate B4. However, a more exhaustive study 
of the problem reveals other factors which make the choice less obvious. 



S-2^ 



5.4.2 Advantages of Simulating B4 (In addition to B1) 

0. Offers least change for the B4 user. In practice, probably no 
change need be made to a user job executing under a simulated 
B4. 

b. It will be the least effort for the vendor. Assumir).:! fhat B4 
development on CENTURY I continues and overlc:^-:: fhe inlrG- 
duction of the IPL, then continuing changes to Pt v/Ili be c^ccoi • 
odated automatical iy. 

c. The host system or the simulator need not provide B4 features 
not provided by stg.nd-aIoneBl. 

5.4.3 Disadvantages of Simulating B4 (In addition to B*l) 

a. Several functions will be executed redundantly by B4 and the 
host system. 

b. Changes will have to be made to B4. (KAany small changes , no 
large changes identified) 

c. Tlie operator console is difficult (but not j-p-. :[;!>. y ^> <•:.*-,,,; .^-a, 
. d. Performance will be degraded over a pure B! i>irrvj!arion due ro 

the odditionci! code io be executed by the simulafor. 

5.4.4 Memory Requirements 

Wien considering the pros and cons of simulaHng B4 versus Bl/Ihe 
amount of memory required, in addition to that of the user jobs must 
be factored in. For this purpose, the following size estimates were 
used: 
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a. Simulafor - 50 - 80K Byfes (based on several 

simulated efforts on CDC CYBER 70) 

b. 84 Operating System - 64 - 80K Bytes 
€• B3 Operating System - 16K Bytes 

d. B2 Operating Syslem - 7I< Bytes 

e. Bl Operating System - 5K Bytes 

This suggests that a single simulation of B4 h roughly ..ai:v-;lont to 
two versions of 81 being simulated simultaneously, rei .T.nibering, of 
course, that each job under B4 has its own copy of Bl > B4 is able 
to run several Jobs simultaneously, hence memory utilization favors 
the B4 simulation. It is recognized that the memory requirements for 
the simulator have been exaggerated; however, *that is offset by the 
resource allocation problem discussed previously, and the difficult- 
ies inherent in running multiple copies of a Bl simulator. 
Note: Any shared code facility provided by Hie host OS wlH 
invalidate the above argument. 

5.4.5 Summary 

The provision for 84 simulation in add*:-: .i to Bl :.imuIcr1on, oIIowg 
the least change for user and vendor cv :. po-zible mb:^fcn\\a\ per- 
formonce cost !o the u!;or. All three poiiifs appear to be positive 
from the vendor's point of view and therefore it appears as a reasonable 
plan of action. (Performance cost to the user can be translated to 
additional hardware sales for the vendor). 
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5.5 Peripheral Support Issues 

i 

5.5.1 Trans! Honal steps for CENTURY I customers 

For purposes of evaluating the peripheral support issues involved 
in a customer moving through the CENTURY I, II product line the 
following progression paths have been postulated; 



(i) CI H/W 
CI S/W 
CIPERIPHS. 



(ii) a. CI H/W 

> CI S/W 

CIIPERIPHS, 



OR (ii) b. CM H/W (=6150) ~] 
■ — . CII S/W (=CI S/V/) > 

CIPERIPHS. J 

from (iii) a. 



(iv) CII H/W n 

Qom ^ Gil S/W ) 

lin>b: CII PERiPHSj 



,(v) IPL H/W (8600-^6150) 
> CII-S/W 
CII PERIPHS. 
IPLPERIPHS. 



(iii) a. CII H/W "1 

CII S/V/ W(V) 

CM PERIPHS. ' 



(iii) b. CII H/W 

CII S/W A 
CI PERIPHS. ^ 
CM [?ERIPHS. 

(vi) IPL*H/W 
! PL S/W 
IPLPERIPHS. 



->(W) 



Note: Any or all of the above steps may be skipped. (In fact 
some are redundant). 

The distinction between C! I periplierols c'id 1?1. pciip!; i.ali 
may be non existqnt. it is herein defined to be at v/orsi a 
different system utilizaiion of exactly similor phy.'jicai device.-,, 
(i.e., a softv/are difference Only.) 



As per fhe peripherals the above transition network can be 

reduced to the following case analysis: 

I ^^C\ devices 

1 Simulator direct driving peripherals v^.^^^ 

^^Cll devices 



JZ\ devices 
2 Simulation uses host OS l/O devices 

'^IPL devices 

(the double arrow indicates expected utilization riensijy) 



Case 1 is in fact the same case as that for NCR supporting Its 
stand-alone customer base. The results of this NCR support In 
conjunction with the recommended partitioned configuration soiuMon 
will be no additional effort for vendor or customer when moving to 
the IPL- 
Case 2 will invalidate the parititoned configuration solution. It 

essentlolly requires that the host OS and/or slmu!':::::r become 

,■'.'■* 

intimately aware of the inherent charactsristlcs of ]h^ I/O struciures 
and proloccls for both CENTURY I cna I'H. sysi.; ,.: . li e Tollowiric; 
seclloiis Indicate each major clcis of dovice typ:- oecio! 

problem areas and sorne tontorlve solutions for e iv may be r.tajed 

that in genera! this cose compllccles the psocrv ooth vendor and 
customer. The vendor must develop and molnlc^ .• ;rsore compllcaied 
simulator package that is in addition to the standard OS offerings. 
The customer must convert his data files from the CENTURY 1 device 
to the corresponding IPL device. (Perhaps the most complex and 
difficult portion of any conversion effort.) 
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5.5.2 Device Types 

5.5.2.1 Disks ~ It is necessary In the simulator to map the 
physical addresses used by CENTURY I software into 
an address space provided by the host on a similcr device. 
If a word addressable disk space is mnde available on the 
IPL, similar to that on CYBER-70 tou-y, then there are 
few problems. In the genera! ca::e it Vvlil be ncceslvary 
to address the IPL device by byte. Tlie transformation is 
then straightforward, and con be performed at execution 
time by the simulator. 

- The user at some stage will face a conversion problem 
and a utility must be provided for that pu^ This 
utility could either execute from disk to disk or from disk 
to disk via magnetic tape. 

5.5.2.2 Magnetic Tapes - National and internaiionol standords in 
this area make simulation a simple moMer* All 'Ko/ is 
necessary is for the host to dcUv^^r a bloc^: r>r data to the 
simulator, or receive a block fron-i rh^^ si.n'iL'!c:t-or on demand. 
Logical, record handling remains rhe rasponsiblity of the 
simulated system. The simulator must moke approprlato 
character conversions if the new devices are incompatible 
with the old. 

- As a general rule, error processing will be performed by 
the host, and only final status will be delivered to the 
sliuutator. 
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5*5.2.3 Card Readers/Punches - The only problem which 

must be solved is that of code conversion which can 
be readily handled by the simulator. 

- For card punches which have stackers there is an 
ocldilional probicm. The siacker select codes wiii hove to 

I be translated by the simulator v/here equivalent devices are 

available. If there is no equivalent devico then it really 
fells outside the scope of the discussion. However, tfie 
problem can still be solved quite easily by sending 
different stacker output to separate files. 

5.5.2.4 Printers - Current 160 column line printers supported 
by NCR are not expected to be continued in the IPL and 
will not be considered. 

- In the B4 environment spooling presents a problem. 

Spooling basically converts a parallel process liiio a 
serior process for a single printer. If spooling f/. r^imoved 
from B4, then [i4 v/iil have to give ussisrance ; :.. . 
simulator to differentiate betVv'een fh»e same TPLr: 
ernonating from different Bl segments. This prcblem is 
not unique to printers but applies to ail unit record uovices 
which are spooled by B4. The problem is non-serious in 
that if sufficient printers, either real or simulated are 
available, then B4 can handle all print files on-line. 



Many simulated printers may be supplied via host 
spooled files. 

- Different print trains are expected to impose a 
further data transformation on the simulator. Currently 
NCR does not support this facility^ but v/i!I prior !o the 
introduction of the IPL. 

5.5.2.5 Paper- Tape - No particular problems are seen to exisi- 
with paper tape, and either a direct driven device or a 
spooled host service should suffice in much the same way 
as for card readers. Labels vvii I present several difflcui ties 
since the host system will not be able to distinguish them 
from data and in the spooled (host) environment cannot 
label automatically. If trailer labels are utilized to 
carry reconciliatory data from the file then an insolvable 
problem exisrs; 

5.5.2.6 Other Devices - The foliov/ing devices were nol cdd-v 
ressed in detail . 

(i) CRAM - }!v. IPLcq. vGJenl 

(ii) MICR " / : .cidy di trussed eisowhcr'' 

(Hi) OCR - Sinnlar too CRor CP 

(iv) Plolters - l !o problems foreseen 

(v) Mohawk - Normal MT problem 

(vi) Terminals - Already discussed elsewhere 



6.0 COST AND PERFORMANCE ESTIMATES 

In order io devise a true cost/performance estimate, data being gathered by 
other teams (notably System Design) will have to be used. In this section, 
the cost fo NCR/CDC to produce a simulator similar to that described here 

is calculated, along v/ith the performance cz compared to c? CENTURY 1/300, 
end in terms of the percentage of the resources required. 

6.1 Cost to Produce Simulator 

6.1.1 The cost of the simulator Is directly calculable from [he 
number of lines of code in the program. In deriving this 
key figure, heavy reliance vas placc.c on pasf experience 
with similar programs. The data which was gathered is 
shown below. 

Simulator Lines of Code 

a. 1401 on CDC 6600 6000 (est) 

b. 360/20 on CDC 6600 6000 (est) 

c. 315 on NCR Century i 6000 

d. 7600 on CDC 6600/7600 1800^ 

e. 8600 on CDC 6600 6000 

* Excludes I/O simulation. There are 25K--30K lines of 
code covering tliis area and dobucj tools v.'hich cannor 
be broken aport readily. 

On this basis, fhe Century I simulator described in this 

paper is assumed to consist of 6000 lines of assembly code . 



6. 1 .2 Given that there are 21 working days per month, and that 
a programmer can generate ten lines of code per day, then 
the simulator can be written in 5 man-years. The figure of 
10 lines of code per man day is high by industry standards 
but may be justified on two points; the resulting system 

is small, and a high level language v/ill be used for 
implementation. Given the 5 man-year estimate and assuming 
a programmer cost of $50K per year: 
Implementation cost = $250K 

6.1.3 Integration and Validation costs are difficult to assess for 
such efforts. A cost estimate for CDC 3000L emulation on 
CYBER -70 has been set at $1.5M (this is viewed as an 
upper bound for Century simulation). 

6.1.4 Since the code Is small (6000 lines) the error rate will be low - 
perhaps no greater than !%• Assuming such a rate, and 
assurnlng a progran:n*ier correction rate of 10 errors p?!" ;-,:0!Tth^. 
then approximately 6 man rnonlhs per year wil! be required for 
maintenance. 

Malntonance costs - $25 '\ p er year . 

6.2 Performance of Simulator 

6.2.1 The two modes of simulation, imbedded and partitioned, 
discussed in Section 5 are considered in this performance 



analysis. As a. basis for performance estimation, the 
simulation work conducted by J. N, Tomblln of NCR 
has been drawn on very heavily. In this work, the instruction 
set-up has been coded together with 38 of the simpler 
NCR/Century instructions/ Th^so hove been used to run 
timing analyses through a Kendall mix. The results Indicare 
that, given a 660 nsec memory 6150, then the simuioror 5s 
roughly 1-1/3 times as fast as a Century 1/300. (4.3 usee 
versus 6 usee). The design goal of this exercise Is twice tivo 
. Century 1/300, This figure (2X) which is b est case v/i!l be 
used arbitrarily in the following analysis. 

6.2.2 Partitioned mode 

Given that the Century I simulator can execute Century I 
code at twice the rate of a Century 1/300, then 50% 

of ihc processor power on fhe IPL v/Ili be ov. '!oL!e to .: .,". .m 
fPL work • If the IPL mode and simulator rc\cJv are run 
concurrently, and states are switched dyrKx^i : Jly, one; 
overheod when sv/i'lching is 50%, then available iPl. pov/er 
is 25% of its full poientioL The maximum pov/er cvollabio is. 
50% of its total power when ihe overhead is zero. This Is a 
worst case calculation since it is unlikely that typical jobs 
are CPU bound. All unused process time can go to IPL jobs. 
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6,2.3 Imbedded Mode 

Performance In this mode is somewhat less favorable since 
additional overhead is incurred for the following reasons: 

a. Data transformation; 

b. Host interfacing; 

c. Execution of redundant functions. 
Consequently, it is estimated that the simulator will 
execute at a rcte equal to 1-1/2 times that of a Century 1/300 
In this case, the available processor pov/er of the IPL will 

be approximately 15% of its full potential. 
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7.0 SUMMARY OF RECOMMENDED SOLUTIONS 
7*] Parfitioned Conflguraflon 

Can utilize NCR standalone system software as the simulator with minimum 

change. 

Direct drive peripherals OS NCR native devices. 

Utilize *'RJE type" job Interchange between Host O.5. ono simuialed 0,S. 

Applies best to configurations having a small number of peripheral Cv^vices. 

Allows customer and user to continue to use existing operation, 

administrative and usage protocols. 

Least development expense. 

Moderate relative performance (SVYAG) 
- Xeost attractive to user because of disjoint system but least user 

conversion. 
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7,2 Host Imbedded Simulator Support Package 
(with direct driven peripherals) 

- Total configuration control is maintained by Host O.S, 
Common I/O queues and input/output procedures. 

Applies besi" io co^,^gura^ions having a nK;derate to large number of 

peripherals. 

Most development expense. 

Worst relative performance (SWAG). 

- Moderate attractiveness and user conversion. 
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7,3 Host Imbedded Simulator Support Package 

(v/ith peripherals driven thru Host O.S.) 

Take configuration control is maintained by Host O.S. 

Total control of I/O support Is maintained by Host O.S. 

Applies best ro configurovions having a large number of peripherals 

and/or a large real memory capacity. 

Moderate development expense. 

Best relative performance (SWAG). 

Most attractive to users but requires greatest user conversion. 



